Analysis of the Opam CI results:

1. Debian 11, OpenSuse 15.6: Unikraft 0.20.0 uses an attribute introduced in GCC 11 without first testing for it, reported upstream.
2. CentOS 10: conf-python-3 fails to install (repology seems to suggest it packages 3.12, so we might have to update our package).
3. Failures of the linter are due to the fact that it’s over-cautious and rejects virtual packages unless they enter one of its categories (such as conf-).
4. Alpine, CentOS 9, OpenSuse 15.6, OpenSuse Tumbleweed: the C cross compiler to arm64 is not packaged for those distributions, so this fails trying to install conf-aarch64-linux-gnu-gcc.

For 1., I wonder whether we should try to exclude older GCCs, but I don’t know what’s the best way to do so.
For 3. and 4., they are already present in OCaml/Unikraft 1.0.0.

Thanks - also for the CI summary! 🙏

For 4., we might consider adding x-ci-accept-failures entries to silence the red CI lights here on the opam-repo, while still allowing folks on those platforms to install as long as they have a locally installed cross-compiler?

For 4., we might consider adding x-ci-accept-failures entries to silence the red CI lights here on the opam-repo, while still allowing folks on those platforms to install as long as they have a locally installed cross-compiler?

I think I had tried to do that for the previous release but it was failing regardless. If I remember correctly, my conclusion at the time was that this entry was no longer working as hoped.

I've created #28829 to fix 2.

OK, that didn't work... Should the line also be added to conf-aarch64-linux-gnu-gcc? 🤔

OK, that didn't work... Should the line also be added to conf-aarch64-linux-gnu-gcc? 🤔

I had tried that last time for Tumbleweed at least according to the record (1, 2) but we could retry with a better set of exceptions.
But I have the impression that we never run the part of the script that would ignore the failures.

But I have the impression that we never run the part of the script that would ignore the failures.

RUN opam reinstall ocaml-unikraft-toolchain-arm64.0.20.0; \
    res=$?; \
    test "$res" != 31 && exit "$res"; \
    export OPAMCLI=2.0; \
    build_dir=$(opam var prefix)/.opam-switch/build; \
    failed=$(ls "$build_dir"); \
    partial_fails=""; \
    for pkg in $failed; do \
    if opam show -f x-ci-accept-failures: "$pkg" | grep -qF "\"alpine-3.22\""; then \
    echo "A package failed and has been disabled for CI using the 'x-ci-accept-failures' field."; \
    fi; \
    test "$pkg" != 'ocaml-unikraft-toolchain-arm64.0.20.0' && partial_fails="$partial_fails $pkg"; \
    done; \
    test "${partial_fails}" != "" && echo "opam-repo-ci detected dependencies failing: ${partial_fails}"; \
    exit 1

Hm. It seems this checks failure by seeing which directories are left in $(opam var prefix)/.opam-switch/build afterwards. At the bottom of the log I also see opam-repo-ci detected dependencies failing: conf-aarch64-linux-gnu-gcc.1 printed, meaning the script is detecting the conf-file failure.

Looking more at the implementation in opam-repo-ci it matches on exactly the A package failed and has been disabled for CI using the 'x-ci-accept-failures' field-line being printed:
https://github.com/ocurrent/opam-repo-ci/blob/live/service/main.ml#L68
and in the present case, the relevant line is only printed for the failing conf- dependency in the script if we add the x-ci-accept-failures line there too. I'd still be curious to try it out in an attempt to silence some of all these known errors, even if the outcome is nothing more than a better understanding of the CI system... 🤓

So I added a patch that changes the build failure exception in the conf- package. But this obviously generates a lot of noise, as all the (expected) failures for this package come up 🙈

Thanks for triggering a new build after #28829 has been merged! The noise is already significantly down 🥳

A couple of questions:

• What about Freebsd ("freebsd-14.3") and macOS ("macos-homebrew"), would it make sense to include them in x-ci-accept-failures too?
• For 1. could it make sense to add a suitable x-ci-accept-failures to ocaml-unikraft-backend-firecracker-x86_64.0.20.0 accompanied by a suitable comment?
  # debian-11 and opensuse-15.6 ship a too old gcc not supporting attribute reg-general
  After all, those distributions will not change their major version of gcc and you have identified the cause of the failures 🤷

• What about Freebsd ("freebsd-14.3") and macOS ("macos-homebrew"), would it make sense to include them in x-ci-accept-failures too?

Two minds with but a single thought 😄

• For 1. could it make sense to add a suitable x-ci-accept-failures to ocaml-unikraft-backend-firecracker-x86_64.0.20.0 accompanied by a suitable comment?

Good idea, thank you!